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FOREWORD 


This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the Software and 
Systems Engineering Sectional Committee had been approved by the Electronic and IT Division Council. 


This Indian Standard provides a model for establishing, implementing, operating, monitoring, reviewing, 
maintaining and improving the software development management system (SDMS). 


The purpose of an SDMS is to ensure that SDUs put systems and structures in place to ensure that the projects they 
execute systematically safeguard against product and execution environment risks. In current practice, projects 
have quality plans to ensure that requirements are identified, agreed upon and addressed systematically, and 
risk management plans to identify and mitigate project risks. However, it has been observed that these plans 
often tend to be deficient in a couple of areas: risks associated with the project execution (environment) are not 
identified and addressed systematically; and sometimes key non-functional concerns are missed because the focus 
is on functional requirements and some of the non-functional aspects that are of immediate concern to particular 
stakeholders. In the past, there have been incidents associated with leakage of critical information from software 
development units that have generated considerable concern in potential customers; there have also been incidents 
where implicit non-functional requirements such as security were not identified and addressed, leading later on to 
high-profile incidents. 


The composition of the Committee responsible for the formulation of this standard is given in Annex C. 
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INTRODUCTION 


The SDMS standard is aimed at ensuring that any 
conformant organization in India that delivers software 
will have systems in place at the level of business units 
(SDUs) that will identify quality requirements based 
on threat assessment and support SDUs to choose 
mitigation controls from the pre-defined annexure 
controls listed in Annex B. Thereby it will give 
confidence to customers of Indian software industry 
that any organization that conforms to this standard will 
have systematic identification of quality requirements 
and mitigation of such risks. 


The adoption of a SDMS should be a strategic decision 
for a software development unit (SDU). The design 
and implementation of an organization’s SDMS is 
influenced by their needs and objectives, functional and 
non-functional requirements, the processes employed 
and the size and structure of the SDU. These and their 
supporting systems are expected to change over time. 
It is expected that an SDMS implementation will be 
scaled in accordance with the needs of the SDU, for 
example, a simple situation requires a simple SDMS 
solution. 


Project Management Task | 


This Standard can be used in order to assess conformance 
by interested internal and external stakeholders covered 
in general as developer, user and Owner or producer. 
The process on the usage of this Standard is illustrated 
in Fig. 1 


0.1 Process Approach 


This Indian Standard adopts a process approach for 
establishing, implementing, operating, monitoring, 
reviewing, maintaining and improving a software 
development units’ SDMS. 


An SDU needs to identify and manage many activities 
in order to function effectively. Any activity using 
resources and managed in order to enable the 
transformation of inputs into outputs can be considered 
to be a process. Often the output from one process 
directly forms the input to the next process. 


The application of a system of processes, activities and 
tasks within the SDU, together with the identification and 
interactions of these processes, and their management, 
can be referred to as a “process approach”. 


I Development Task 


Fig. | Process on THE USAGE 
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The process approach for software development 
management process is presented in this Indian Standard 
encourages its users to emphasize the importance of: 


a) Understanding an SDU’s software quality 
requirements and the need to establish policy and 
objectives for establishing and inculcating the 
quality attributes; 


b) Implementing and operating controls to manage 
the software applications risks in the context of 
the SDU’s overall business risks; 


c) Monitoring and reviewing the performance and 
effectiveness of the SDMS; and 


d) Continual improvement based on objective 
measurement. 


This Indian Standard adopts the “Plan-Do-Check-Act” 
(PDCA) model, which is applied to structure all software 
development management (SDM) processes. Fig. 2 
illustrates how a SDMS takes as input the functional 
and non-functional requirements and expectations of 
the interested parties like developer, user, owner and 
through the necessary actions and processes produces 
software quality outcomes that meets those requirements 
and expectations. Fig. 2 also illustrates the links in the 
processes presented in 4, 5, 6, 7 and 8. 


The adoption of the PDCA model will also reflect the 
principles as set out in IS/ISO/TEC 27001 : 2005 but 
governing the software quality attributes. This Indian 
Standard provides a robust model for implementing 
the principles in those guidelines governing risk 
assessment, qualitative design implementation, 
software development management and reassessment. 


Example 1 


The quality requirement might be that ignorance 
of best practices will not cause serious financial 
damage to the software development unit and/or 
cause embarrassment to the organization. 


Example 2 


An expectation might be that if a serious incident 
occurs — perhaps hacking of an organization’s e 
Business web site — there should be people with 
sufficient training in appropriate procedures to 
minimize the impact. 


Table 1 P-D-C-A Phases of SDMS 


Plan (establish the 
SDMS) 


Establish SDMS policy, objectives, 
processes and procedures relevant to 
managing risk and improving software 
quality to deliver results in accordance 
with SU’s overall policies and objectives. 


Do (implement and 
operate the SDMS) 


Implement and operate the SDMS policy, 
controls, processes and procedures. 


Check (monitor and 
review the SDMS) 


Assess and, where applicable, measure 
process performance against SDMS 
policy, objectives and practical 
experience and report the results to 
management for review. 


Act (maintain and 
improve the SDMS) 


Take corrective and preventive actions, 
based on the results of the internal 
SDMS audit and management review 
or other relevant information, to achieve 
continual improvement of the SDMS. 


0.2 Compatibility with Other Management Systems 


This Indian Standard is aligned with IS/ISO 9001 : 
2000, IS/ISO IEC 27001, and IS/ISO 20000 in order 
to support consistent and integrated implementation 
and operation with related management standards. One 
suitably designed management system can thus satisfy 
the requirements of all these standards. 


This Indian Standard is designed to enable the software 
development unit to align or integrate its SDMS with 
related management system requirements. 


Establish Requirement for 


Functional Requirement 


Feeback from interested parties 


Maintain and Improve 
SDMS 


Request for comments 


Managed Process 


Software Quality 


Design and implement 
SDMS 


Measure and 
Monitor SDMS 


Fic. 2 PDCA Mopbet AppLigp SDMS Process 
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Indian Standard 


SOFTWARE QUALITY ENGINEERING — 
DEVELOPMENT PROCESS — 
SOFTWARE DEVELOPMENT MANAGEMENT 
SYSTEM (SDMS) — REQUIREMENTS 


1 SCOPE 


This Standard covers all types of Software development 
unit (for example, standalone, web-based, embedded). 
This Indian Standard specifies the requirements for 
establishing, implementing, operating, monitoring, 
reviewing, maintaining and improving a documented 
Software Development Management System (SDMS) 
within the context of the software development unit 
(SDU) and its overall business risks. It specifies 
requirements for the implementation of quality 
attributes customized to the needs of individual SDU 
or parts thereof. 


The SDMS is designed to ensure the selection of 
adequate and proportionate quality-attribute controls 
that protect from application flaws in terms of 
functional, security, usability, performance, safety 
requirements and give confidence to interested 
parties. 


It covers the following; 
a) Identification of software requirements, 
b) Identification of quality requirements, 


c) Identification of software development controls 
and tasks, and 


d) Auditing and conformance procedures. 


2 REFERENCES 


The standards listed in Annex A contain provisions 
which, through reference in this text, constitute 
provisions of this standard. At the time of publication, 
the editions indicated were valid. All standards are 
subject to revision, and parties to agreements based 
on this standard are encouraged to investigate the 
possibility of applying the most recent editions of the 
standards listed in Annex A. 


In case the Software Development Unit (SDU) 
already has an operative business process management 
system ( for example, in relation with IS/ISO 9001, 
ISASO/IEC 27001 or IS/ISO/IEC 20000-1), it is 
preferable in most cases to satisfy the requirements 
of this Standard within this existing management 
system. 


3 TERMINOLOGY 


3.1 For the purposes of this document, the following 
terms and definitions apply. 


3.1.1 Asset — Anything that has value to the 
organization ((see ISO/IEC 13335-1: 2004)). 


3.1.2 Software Feature — A distinguishing 
characteristic of a software item (for example, 
performance, portability, or functionality) (see IEEE 
829 : 1983). 


3.1.3 A software characteristic specified or implied 
by requirements documentation (for example, 
functionality, performance, attributes, or design 
constraints). (see IEEE 1008 : 1987). 


3.1.4 Software Item — Source code, object code, job 
control code, control data, or a collection of these 
items. (see IEEE 829 : 1983). 


3.1.5 Software Quality — The discipline of software 
quality is a planned and systematic set of activities to 
ensure quality is built into the software. It consists of 
software quality assurance, software quality control, 
and software quality engineering. As an attribute, 
software quality is: 


a) The degree to which a system, component, or 
process meets specified requirements; and 


b) The degree to which a system, component, 
or process meets customer or user needs or 
expectations (see ISO/IEC/IEEE 24765 : 2010). 


3.1.6 Quality Event — An identified occurrence of a 
system, service or network state indicating a possible 
breach software development policy or failure of 
safeguards, or a previously unknown situation that 
may be quality relevant (see ISO/IEC TR 18044 : 
2004) . 


3.1.7 Quality Incident — A single or a series of 
unwanted or unexpected quality events that have a 
significant probability of compromising business 
operations and threatening software quality (see ISO/ 
IEC TR 18044 : 2004) . 
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3.1.8 Software Development Management System — 
This is a part of the overall management system that 
addresses software engineering quality principles in 
software development units, based on a business risk 
approach, to establish, implement, operate, monitor, 
review, maintain and improve software quality. 

NOTE — The management system includes organizational 

structure, policies, planning activities, responsibilities, 

practices, procedures, processes and resources. 


3.1.9 Integrity — The property of safeguarding the 
accuracy and completeness of assets (see IS/ISO/IEC 
13335-1 : 2004). 


3.1.10 Residual Risk — The risk remaining after risk 
treatment (see ISO/IEC Guide 73: 2002, IS/ISO 31000 
: 2009). 


3.1.11 Risk Acceptance — Decision to accept a risk 
(see ISO/IEC Guide 73 : 2002). 


3.1.12 Risk Analysis — Systematic use of information 
to identify sources and to estimate the risk (see ISO/ 
IEC Guide 73 : 2002). 


3.1.13 Risk Assessment — Overall process of risk 
analysis and risk evaluation (see ISO/IEC Guide 73 : 
2002) . 


3.1.14 Risk Evaluation — Process of comparing the 
estimated risk against given risk criteria to determine 
the significance of the risk (see ISO/IEC Guide 73 : 
2002). 


3.1.15 Risk Management — Coordinated activities to 
direct and control an organization with regard to risk 
(see ISO/IEC Guide 73 : 2002). 


3.1.16 Risk Treatment — Process of selection and 
implementation of measures to modify risk (see ISO/ 
IEC Guide 73 : 2002). 


3.1.17 Statement of Applicability — Documented 
statement describing the control objectives and controls 
that are relevant and applicable to the organization’s 
SDMS(see IS/ISO/IEC 27001 : 2013). 


NOTE — Control objectives and controls are based on the 
results and conclusions of the risk assessment and risk treatment 
processes, legal or regulatory requirements, contractual 
obligations and the organization’s business requirements for 
information security. 


3.1.18 Software Development Unit — A section or 
an entity that studies, designs, develops, tests and/ 
or maintains software applications (In-house or 
outsourced development) 


3.2 Abbreviations 


For the purpose of this standard the following 
abbreviations shall apply: 


Description Abbreviations 
Software development management SDMS 
system 
Software development unit SDU 
Risk assessment RA 
International Organization for ISO 
Standardization 
Statement of applicability SOA 
Failure mode and effects analysis FMEA 
Fault tree Analysis FTA 
Business process BP 
Plan, Do, Check and Act PDCA 
Software requirement specification SRS 
Information Technology IT 


4 SOFTWARE DEVELOPMENT 
MENT PROCESS 


MANAGE- 


4.1 General Requirements 


The SDU shall establish, implement, operate, monitor, 
review, maintain and improve a documented SDMS 
within the context of the SDU’s overall business 
activities and the risks it faces due to lack of quality. 
For the purposes of this Indian Standard the process 
used is based on the PDCA model shown in Fig. 1. 


4.2 Establishing and Managing the SDMS 


4.2.1 Establish the SDMS 
The SDU shall do the following: 


a) Define the scope and boundaries of the SDMS in 
terms of the characteristics of the application, the 
SDU, its location, and technology, and including 
details of and justification for any exclusion from 
the scope (see 1). 

b) Define an SDMS policy 
characteristics of the application, 
location, and technology that: 


in terms of the 
SDU, its 


1) Includes a framework for setting objectives 
and establishes an overall sense of direction 
and principles for action with regard to quality 


requirement; 

2) Takes into account business obligations and 
legal regulatory requirements, 

3) Aligns with the organization’s strategic 


threat management context in which the 
establishment and maintenance of the SDMS 
will take place; 

4) Establishes criteria against which threat will 
be evaluated (see c) of CI 4.2.1); and 


5) Has been approved by management. 


c) Define the threat assessment approach of the 


d) 


e) 


organization. 


1) Identify a threat assessment methodology 
that is suited to the SDMS, and the identified 
requirement for the inculcation of software 
quality based on the software requirement; and 


2) Establish criteria for accepting threats and 
associated vulnerabilities expected during 
development and identify the acceptable levels 
of risk associated with the threat. (see f) of 
CI 5.1). 


The threat assessment methodology selected shall 
ensure that threat assessments produce comparable 
and reproducible results. 


Identify the risks. 


1) Identify the assets within the scope of the 
SDMS, and the owners” of these assets. 


2) Identify the threats to those SDU and its 
associated functions developed 


3) Identify the vulnerabilities that might be 
exploited by the threats. 


4) Identify the impacts that losses of quality 
that may have on the SDU and its functions 
developed 


Analyse, evaluate and plan countermeasures for 
the threat: 


1) Assess the business impacts upon the SDU 
that might result from application failures, 
taking into account the consequences of a 
loss of functional and non-functional attribute 
(functionality, safety, security, exception, 
performance and usability of the application). 


2) Assess the realistic likelihood of security 
failures occurring in the light of prevailing 
threats and vulnerabilities, and impacts 
associated with these assets, and the controls 
currently implemented. 


3) Estimate the levels of risks assessed for a 
threat. 


4) Determine whether the risks are acceptable 
or require treatment using the criteria for 
accepting risks established in 2) of c) of 4.2.1. 

Identify and evaluate options for the treatment of 

risks. 

Possible actions include: 

1) Applying appropriate controls; 

2) knowingly and objectively accepting risks, 
providing they clearly satisfy the organization’s 


policies and the criteria for accepting risks 
(see 2) of c) of 4.2.1); 


g) 


h) 


ID) 


k) 


a) 
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3) Avoiding risks; and 
4) Transferring the associated business risks to 
other parties, for example, insurers, suppliers. 


Select control objectives and controls for the 
treatment of risks. 


Control objectives and controls shall be selected 
and implemented to meet the requirements 
identified by the risk assessment and risk treatment 
process. This selection shall take account of the 
criteria for accepting risks (see 2) of c) of 4.2.1) 
as well as legal, regulatory and contractual 
requirements. 


The control objectives and controls from Annex B 
shall be selected as part of this process as suitable 
to cover the identified requirements. 


The control objectives and controls listed in 

Annex B are not exhaustive and additional control 

objectives and controls may also be selected. 
NOTE — Annex B contains a comprehensive list of 
control objectives and controls that have been found to 
be commonly relevant in organizations. Users of this 
Indian standard are directed to Annex B as a starting 
point for control selection to ensure that no important 
control options are overlooked. 

Obtain management approval of the proposed 

residual risks. 


Obtain management authorization to implement 
and operate the SDMS. 


Prepare a Statement of Applicability. 


A Statement of Applicability shall be prepared that 
includes the following: 


1) the control objectives and controls selected 
in g) of CI 4.2.1 and the reasons for their 
selection; 


2) the control objectives and controls currently 
implemented (see 2) of e) of CI 4.2.1); and 


3) the exclusion of any control objectives and 
controls in Annex B and the justification for 
their exclusion. 

NOTE — The statement of applicability provides a summary 

of decisions concerning risk treatment. Justifying exclusions 

provides a cross-check that no controls have been inadvertently 
omitted. 


4.2.2 Implement and Operate the SDMS 


The organization shall do the following: 


Formulate a risk treatment plan that identifies 
the appropriate management action, resources, 
responsibilities and priorities for managing 
information security risks (see 5). 


1) NOTE—The term ‘owner’ identifies an individual or entity that has approved management responsibility for controlling the requirement, 
design, coding and maintenance, use and quality of the applications. The term ’owner’ does not mean that the person actually has any 
property rights to the asset. 
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b) Implement the risk treatment plan in order to 
achieve the identified control objectives, which 
includes consideration of funding and allocation 
of roles and responsibilities. 


c) Implement controls selected in g) of 4.2.1 to meet 
the control objectives. 


d) Define how to measure the effectiveness of the 
selected controls or groups of controls and specify 
how these measurements are to be used to assess 
control effectiveness to produce comparable and 
reproducible results (see c) of 4.2.3). 

NOTE — Measuring the effectiveness of controls allows 
managers and staff to determine how well controls achieve 
planned control objectives. 

e) Implement training and awareness programs 
(see 5.2.2). 


f) Manage operation of the SDMS. 
g) Manage resources for the SDMS (see 5.2). 


h) Implement procedures and other controls capable 
of enabling prompt detection of security events 
and response to security incidents (see a) of 4.2.3). 


4.2.3 Monitor and Review the SDMS 


The organization shall do the following: 


a) Execute monitoring and reviewing procedures and 
other controls to: 


1) promptly detect errors in the results of 
processing; 

2) promptly identify attempted and successful 
security breaches and incidents; 


3) enable management to determine whether 
the security activities delegated to people or 
implemented by information technology are 
performing as expected; 

4) help detect security events and thereby prevent 
security incidents by the use of indicators; and 

5) Determine whether the actions taken to resolve 
a breach of security were effective. 

b) Undertake regular reviews of the effectiveness of 
the SDMS (including meeting SDMS policy and 
objectives, and review of security controls) taking 
into account results of security audits, incidents, 


results from effectiveness measurements, 
suggestions and feedback from all interested 
parties. 


c) Measure the effectiveness of controls to verify 
that security requirements have been met. 


d) Review risk assessments at planned intervals 
and review the residual risks and the identified 
acceptable levels of risks, taking into account 
changes to: 

1) the organization; 


2) technology; 


3) business objectives and processes; 
4) identified threats; 
5) effectiveness of the implemented controls; and 


6) external events, such as changes to the legal or 
regulatory environment, changed contractual 
obligations, and changes in social climate. 


e) Conduct internal SDMS audits at planned intervals 
(see 6). 

NOTE — Internal audits, sometimes called first party audits, 
are conducted by, or on behalf of, the organization itself for 
internal purposes. 

f) Undertake a management review of the SDMS on 
a regular basis to ensure that the scope remains 
adequate and improvements in the SDMS process 
are identified (see 7.1). 


g) Update security plans to take into account the 
findings of monitoring and reviewing activities. 


h) Record actions and events that could have an 
impact on the effectiveness or performance of the 
SDMS (see 4.3.3). 


4.2.4 Maintain and Improve the SDMS 
The organization shall regularly do the following: 


a) Implement the identified improvements in the 
SDMS. 


b) Take appropriate corrective and preventive actions 
in accordance with 8.2 and 8.3. Apply the lessons 
learnt from the security experiences of other 
organizations and those of the organization itself. 

c) Communicate the actions and improvements to all 
interested parties with a level of detail appropriate 
to the circumstances and, as relevant, agree on 
how to proceed. 

d) Ensure that the improvements achieve their 
intended objectives. 


4.3 Documentation Requirements 


4.3.1 General 


Documentation shall include records of management 
decisions, ensure that actions are traceable to 
management decisions and policies, and ensure that the 
recorded results are reproducible. 


It is important to be able to demonstrate the relationship 
from the selected controls back to the results of 
the risk assessment and risk treatment process, and 
subsequently back to the SDMS policy and objectives. 


The SDMS documentation shall include: 


a) documented statements of the SDMS policy 
(see b) of 4.2.1) and objectives; 


b) the scope of the SDMS (see a) of 4.2.1); 
c) procedures and controls in support of the SDMS; 


d) adescription of the Threat assessment methodology 
(see c) of 4.2.1); 


e) the Threat assessment report (see c) to g) of 4.2.1); 


f) the treatment plan for risks associated with the 
threat (see b) of 4.2.2); 


g) documented procedures needed by the organization 
to ensure the effective planning, operation and 
control of its information security processes and 
describe how to measure the effectiveness of 
controls (see c) of 4.2.3); 


h) Records required by this Indian standard (see 
4.3.3); and 


j) The Statement of Applicability. 


NOTES 


1 Where the term “documented procedure” appears within this 
Indian standard, this means that the procedure is established, 
documented, implemented and maintained. 


2 The extent of the SDMS documentation can differ from one 
organization to another owing to: 
a) the size of the organization, and the type of its 
activities; and 
b) the scope and complexity of software quality 
requirement and the system being managed. 


3 Documents and records may be in any form or type of 
medium. 


4.3.2 Control of Documents 


Documents required by the SDMS shall be protected 
and controlled. A documented procedure shall be 
established to define the management actions needed 
to: 


a) approve documents for adequacy prior to issue; 


b) review and update documents as necessary and re- 
approve documents; 


c) ensure that changes and the current revision status 
of documents are identified; 


d) ensure that relevant versions of applicable 
documents are available at points of use; 


e) ensure that documents remain legible and readily 
identifiable; 


f) ensure that documents are available to those 
who need them, and are transferred, stored and 
ultimately disposed of in accordance with the 
procedures applicable to their classification; 


g) ensure that documents of external origin are 
identified; 


h) ensure that the distribution of documents is 
controlled; 


j) Prevent the unintended use of obsolete documents; 
and 


k) apply suitable identification to them if they are 
retained for any purpose. 
4.3.3 Control of Records 


Records shall be established and maintained to 
provide evidence of conformity to requirements and 
the effective operation of the SDMS. They shall be 
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protected and controlled. The SDMS shall take account 
of any relevant legal or regulatory requirements and 
contractual obligations. Records shall remain legible, 
readily identifiable and retrievable. The controls 
needed for the identification, storage, protection, 
retrieval, retention time and disposition of records shall 
be documented and implemented. 


Records shall be kept of the performance of the process 
as outlined in 4.2 and of all occurrences of significant 
security incidents related to the SDMS. 


For example: Visitors’ book, audit reports and 
completed access authorization forms. 


5 MANAGEMENT RESPONSIBILITIES 


5.1 Management Commitment 


Management shall provide evidence of its commitment 
to the establishment, implementation, operation, 
monitoring, review, maintenance and improvement of 
the SDMS by: 


a) Establishing an SDMS policy; 


b) Ensuring that SDMS objectives and plans are 
established; 


c) Establishing roles and responsibilities for software 
development; 


d) Communicating to the organization the importance 
of meeting quality objectives and conforming to 
the SDMS policy, its responsibilities under the 
law and the need for continual improvement; 


e) Providing sufficient resources to establish, 
implement, operate, monitor, review, maintain and 
improve the SDMS (see 5.2.1); 


f) Deciding the criteria for accepting risks associated 
with the threats and optimization of quality 
controls; 

g) Ensuring that internal SDMS audits are conducted 
(see 6); and 


h) Conducting management reviews of the SDMS 
(see 7). 
5.2 Resource Management 


5.2.1 Provision of Resources 


The organization shall determine and provide the 
resources needed to: 


a) Establish, implement, operate, monitor, review, 
maintain and improve an SDMS; 

b) Ensure that software quality requirement 
procedures support the business requirements; 

c) Identify and address legal and regulatory 
requirements and contractual software quality 
obligations; 

d) Maintain adequate software quality by correct 
application of all implemented controls; and 
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e) Carry out reviews when necessary, and to react 
appropriately to the results of these reviews; and 
where required, improve the effectiveness of the 
SDMS. 


5.2.2 Training, Awareness and Competence 


The organization shall ensure that all personnel who 
are assigned responsibilities defined in the SDMS are 
competent to perform the required tasks by: 


a) Determining the necessary competencies for 
personnel performing work affecting the SDMS; 


b) Providing training or taking other actions (for 
example, employing competent personnel) to 
satisfy these needs; 


c) Evaluating the effectiveness of the actions taken; 
and 


d) Maintaining records of education, training, skills, 
experience and qualifications (see 4.3.3). 


The organization shall also ensure that all relevant 
personnel are aware of the relevance and importance 
of their software development activities and how they 
contribute to the achievement of the SDMS objectives. 


6 INTERNAL SDMS AUDITS 


The organization shall conduct internal SDMS audits 
at planned intervals to determine whether the control 
objectives, controls, processes and procedures of its 
SDMS: 


a) Conform to the requirements of this Indian 
standard and relevant legislation or regulations; 


b) Conform to the 
requirements; 


identified software quality 


c) Are effectively implemented and maintained; and 
d) Perform as expected. 


An audit programme shall be planned, taking into 
consideration the status and importance of the processes 
and areas to be audited, as well as the results of previous 
audits. The audit criteria, scope, frequency and methods 
shall be defined. The selection of auditors and conduct 
of audits shall ensure objectivity and impartiality of the 
audit process. Auditors shall not audit their own work. 


The responsibilities and requirements for planning 
and conducting audits, and for reporting results and 
maintaining records (see 4.3.3) shall be defined in a 
documented procedure. 


The management responsible for the area being audited 
shall ensure that actions are taken without undue delay 
to eliminate detected nonconformities and their causes. 
Follow-up activities shall include the verification of the 
actions taken and the reporting of verification results 
(see 8). 

NOTE — ISO 19011 : 2002, Guidelines for quality and/or 


environmental management systems auditing, may provide 
helpful guidance for carrying out the internal SDMS audits. 


7 MANAGEMENT REVIEW OF THE SDMS 


7.1 General 


Management shall review the organization’s SDMS at 
planned intervals (at least once a year) to ensure its 
continuing suitability, adequacy and effectiveness. 
This review shall include assessing opportunities 
for improvement and the need for changes to the 
SDMS, including the software quality policy and 
quality objectives. The results of the reviews shall be 
clearly documented and records shall be maintained 
(see 4.3.3). 


7.2 Review Input 

The input to a management review shall include: 
a) Results of SDMS audits and reviews; 
b) Feedback from interested parties; 


c) Techniques, products or procedures, which could 
be used in the organization to improve the SDMS 
performance and effectiveness; 


d) Status of preventive and corrective actions; 


e) Vulnerabilities or threats not adequately addressed 
in the previous risk assessment; 


f) Results from effectiveness measurements; 


g) Follow-up actions from previous management 
reviews; 


h) Any changes that could affect the SDMS; and 


j) Recommendations for improvement. 


7.3 Review Output 


The output from the management review shall include 
any decisions and actions related to the following: 


a) Improvement of the effectiveness of the SDMS. 


b) Update of the risk assessment and risk treatment 
plan. 


c) Modification of procedures and controls that effect 
information security, as necessary, to respond to 
internal or external events that may impact on the 
SDMS, including changes to: 


1) business requirements; 
2) software quality requirements; 


3) business processes effecting the existing 
business requirements; 


4) regulatory or legal requirements; 
5) contractual obligations; and 
6) levels of risk and associated threats/or criteria 
for selection mitigation control to ensure 
quality. 
d) Resource needs. 
e) Improvement to how the effectiveness of controls 
is being measured. 


8 SDMS IMPROVEMENT 


8.1 Continual Improvement 


The organization shall continually improve the 
effectiveness of the SDMS through the use of the 
software development policy, software quality 
objectives, audit results, analysis of monitored events, 
corrective and preventive actions and management 
review (see 7). 


8.2 Corrective Action 


The organization shall take action to eliminate the cause 
of nonconformities with the SDMS requirements in 
order to prevent recurrence. The documented procedure 
for corrective action shall define requirements for: 


a) Identifying nonconformities; 
b) Determining the causes of nonconformities; 


c) Evaluating the need for actions to ensure that 
nonconformities do not recur; 


d) Determining and implementing the corrective 
action needed; 


e) Recording results of action taken (see 4.3.3); and 
f) Reviewing of corrective action taken. 
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8.3 Preventive Action 


The organization shall determine action to eliminate 
the cause of potential nonconformities with the SDMS 
requirements in order to prevent their occurrence. 
Preventive actions taken shall be appropriate to the 
impact of the potential problems. The documented 
procedure for preventive action shall define 
requirements for: 


a) Identifying potential nonconformities and their 
causes; 


b) Evaluating the need for action to prevent 
occurrence of nonconformities; 


c) Determining and implementing preventive action 
needed; 


d) Recording results of action taken (see 4.3.3); and 
e) Reviewing of preventive action taken. 


The organization shall identify the possible threats 
and identify preventive action requirements focusing 
attention on significantly changed risks. 


The priority of preventive actions shall be determined 
based on the results of the threat assessment. 


NOTE — Action to prevent nonconformities is often more 
cost-effective than corrective action. 
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ANNEX A 
( Clause 2 ) 


LIST OF REFFERED INDIAN AND INTERNATIONAL STANDARDS 


IS No./ 
Other Publications 


IS/ISO/IEC 13335-1 : 2004 


IS/ISO/IEC 27001 : 2013 


IS/ISO 31000 : 2009 

IS/ISO 19011 : 2002 
ISO/IEC/IEEE 24765 : 2010 
ISO/IEC TR 18044 : 2004 


ISO/IEC Guide 73 : 2002 
IEEE Std 1008 : 1987 
IEEE 829 : 1983 


Title 


Information technology — Security techniques — Management of information and communications 
technology security: Part 1 Concepts and models for information and communications technology 
security management 


Information technology — Security techniques — Information security management systems — 
Requirements 


Risk management — Principles and guidelines 
Guidelines for auditing management systems 
Systems and software engineering — Vocabulary 


Information technology — Open Systems Interconnection — The directory: Overview of concepts, 
models and services: Part 1 


Risk management — Vocabulary 
IEEE standard for software unit testing 


IEEE standard for software test documentation 
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ANNEX B 
( Clause 4.2.1 ) 


CONTROL OBJECTIVES AND CONTROLS 


The control objectives and controls listed in Table 2 are directly derived from and aligned with this Indian standard. 
The lists in Table 2 are not exhaustive and an organization may consider that additional control objectives and 
controls are necessary. Control objectives and controls from this table shall be selected as part of the SDMS 
process specified in 4.2.1. 


Table 2 Control Objectives and Controls 


a) Requirement Analysis 


1) Software development management policy 


Objective: To provide management direction and support for software development in accordance with business requirements and relevant 
laws and regulations. 


i) 


x) 


xi) 


xii) 


xiii) 


xiv) 


xv) 


xvi) 


xvii) 


xviii) 


xix) 


Xx) 


xxi) 


Software 
document 


development policy 


Review of the information software 
development policy 


Quality requirements 
specification 


analysis and 


Threat Analysis 
Abuse/Misuse Case 


Document Security Requirement 


Document Requirement Checklist 


Determine Operational Profile 


Categorization of Failures 


List Customer Reliability needs 


Conduct Trade of Studies 


List Reliability Objective 


Scenario Analysis 


Hardware interface 


Analysis 


requirement 


Document Exception Requirements 


Document Exception Checklist 


Speed and Latency Requirement 


Analysis 
Safety critical Requirement Analysis 
Capacity requirement Analysis 


Longevity Requirement Analysis 


Document usability requirement 


Software development system policy document shall be approved by management, 
and published and communicated to all employees and relevant external parties. 


Software development policy shall be reviewed at planned intervals or if significant 
changes occur to ensure its continuing suitability, adequacy, and effectiveness. 


Statements of business requirements for new information systems, or enhancements 
to existing information systems shall specify the requirements for software quality. 


Shall define procedure and practice the threat analysis 
Shall define formal method to derive the abuse and misuse test cases 


Shall establish procedure to document, derive and shall practice the template for 
addressing the security requirements 


Shall establish procedure to document, derive and shall practice the checklist for 
addressing the requirements 


Shall define the procedure and metrics to determine the operational profile to address 
the software reliability requirement 


Shall define a formal procedure to list and categories the failures associated with the 
software development process 


Shall address reliability needs and shall be clearly identified and an inventory of all 
important needs are drawn up and maintained. 


Shall identify requirements shall be addressed and conduct formal trade of studies on 
existing application 

Shall address all reliability objectives and shall be clearly identified and an inventory 
of all important objectives are drawn up and maintained. 


Shall define and derive a procedure to conduct a formal scenario analysis addressing 
the requirements listed in the software requirement specification 


Shall define and derive a procedure to conduct a formal Hardware interface requirement 
Analysis addressing the requirements listed in the software requirement specification 


Shall establish procedure to document, derive and practice the template for addressing 
the exception requirements 


Shall establish procedure to document, derive and practice the template for addressing 
the exception requirements 


Shall define and derive a procedure to conduct a formal speed and latency requirement 
Analysis addressing the requirements listed in the software requirement specification 


Shall define and derive a procedure to conduct a formal safety critical requirement 
Analysis addressing the requirements listed in the software requirement specification 


Shall define and derive a procedure to conduct a formal capacity requirement Analysis 
addressing the requirements listed in the software requirement specification 


Shall define and derive a procedure to conduct a formal longevity requirement 
Analysis addressing the requirements listed in the software requirement specification 


Shall establish procedure to document, derive and practice the template for addressing 
the usability requirements 
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xxii) 


xxiii) 


xxiv) 


KKV) 


Document usability Checklist 


Contextual Interview 


Document performance Checklist 


Software Requirement specification 


b) Design analysis 


1) Software design analysis 


Objective: To design and inculcate quality practices i 


i) 


viii) 


ix) 


x) 


xi) 


xii) 


xiii) 


xiv) 


xv) 


xvi) 


xvii) 


xviii) 


xix) 


KK) 


xxi) 


Security Architecture 


Listing Security Principles 


Document Software Surface 


Threat Modeling 


Risk Analysis 


Reliability Block Diagram 


Redundancy Analysis 


FTA Software 


FMEA-Software 


Reliability Prediction 


Document Reliability Design 


Document Reliability Requirements 


Document Reliability Checklist 


Verification of Reliability Requirements 


Design Structure Analysis 


Dataflow Diagram 


Threat Surface Analysis 


Handle/Terminate Analysis 


Verification of Exception Requirement 


H/W Analysis 


Prototype Development 


Table 2 ( Continued ) 


Shall establish procedure to document, derive and practice the template for addressing 
the usability requirements 


Shall define and derive a procedure to conduct a formal contextual interview with 
the user addressing the requirements listed in the software requirement specification 


Shall establish procedure to document, derive and practice the template for addressing 
the performance requirements 


Shall define a template and develop a document addressing all the functional 
requirements of application. 


nto software application. 


Shall define formal security architecture procedures, and controls shall be in place to 
protect the possible threats 


Shall list the security principles shall be classified in terms of its requirements, 
sensitivity and criticality to the application 


Shall define formal software surface prone to be attached and shall derive methodology 
to identify the surface attack 


Shall define and drive a procedure to conduct a Threat modeling analysis addressing 
various threats and vulnerabilities 


Shall define and drive a procedure to conduct a Risk analysis addressing various 
threats and vulnerabilities 


Shall define and drive a procedure to conduct a RBD analysis addressing the reliability 
bjectives and requirements specified in the reliability requirement specification 


o 
Shall establish a control to adapt the redundancy mechanism to establish the 
availability of the application over a specified time under stated conditions 


hall define and drive a procedure to conduct a FTA analysis addressing the reliability 
bjectives and requirements specified in the reliability requirement specification 


non 


hall define and drive a procedure to conduct a FMEA analysis addressing the reliability 
objectives and requirements specified in the reliability requirement specification 


Shall define and drive a procedure to conduct a Reliability prediction addressing 
the reliability objectives and requirements specified in the reliability requirement 
specification 


Shall establish procedure to document, derive and practice the template for addressing 
the reliability design requirements 


Shall establish procedure to document, derive and practice the template for addressing 
the reliability requirements 

Shall establish procedure to document, derive and practice the template for addressing 
the reliability requirements 

Shall establish a Control and adapt procedure for verification of reliability requirements 
meeting the reliability objectives 


Shall define and drive a procedure to conduct a Design structure analysis addressing 
the reliability objectives and requirements specified in the reliability requirement 
specification 


Shall define, drive and control a procedure to draw dataflow diagram meeting the 
reliability objectives and requirements specified in the reliability requirement 
specification 


Shall define and drive a procedure to threat surface analysis to address the security 
requirement specification 


Shall define and drive a procedure to handle and terminate analysis to address the 
security requirement specification 


Shall have a control and verify the exception requirement in the design 


Shall define and drive a procedure to hardware analysis to address the security 
requirement specification 


Shall define and drive a procedure to develop prototype and test to address the software 
requirement specification. 
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xxii) 


xxiii) 


xxiv) 


KKV) 


xxvi) 


xxvii) 


Prototype Evaluation 


Impact Analysis 


Document Performance Guidelines 


Verify Performance Requirements 


Verify Usability Requirements 


Design document 


c) Software Code management 


1) Coding responsibility 
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Table 2 ( Continued ) 


Shall define and drive a procedure to evaluate prototype addressing the software 
requirement specification 


Shall define and drive a procedure to practice impact analysis addressing the software 
requirement specification 


Shall establish procedure to document, derive and practice the template for addressing 
the performance guidelines 


Shall establish procedure to document, derive and practice the template for verifying 
the performance requirements 


Shall establish procedure to document, derive and practice the template for verifying 
the usability requirements 


Shall drive and document the design requirement and shall be controlled. 


Objective: To practice and maintain appropriate coding guidelines and Indian Standard to ensure quality 


i) 


xiii) 


xiv) 


KV) 


Static Analysis 


Document Code 
Code Review 


Verification of Security Reguirements 


Coding 
Static Analysis Measurements 


Black Box Testing and Measurement 


Code Verification 
Requirement 


Reliability 


Unit Test 


Verification of Exception Requirement 


Code Bottle Neck Assessment 


Lock Contention 


Verification of Design Requirement 


Code Moderation 


Code document 


d) Software Test Management 


1) Test case design, verification and validation 


Shall define and drive a procedure to static analysis to address the security requirement 
specification 


Shall establish procedure to document the code to securely store and retrieve 
Shall establish procedure to review the code to ensure software quality requirements 


Shall establish a procedure to verify the requirements of the software quality 
requirements 


Shall establish procedure and guideline for coding 
Shall establish procedure and metrics for static analysis 


Shall establish procedure for black box testing and shall derive metrics for its 
measurements 


Shall build a Control and adapt procedure for code verification of reliability 
requirements meeting the reliability objectives 


Shall establish procedure and metrics for unit test 


Shall build a control and adapt procedure for code verification of exception 
requirements 


Shall establish procedure for black box testing and shall derive metrics for its 
measurements 


Shall establish procedure for lock contention level and shall derive metrics for its 
measurements 


Shall build a Control and adapt procedure for verification of design requirements for 
software performance 


Shall build a Control and adapt procedure for code moderation for software 
performance 


Shall generate a formal code document template and shall maintain the code with 
adequate security. 


Objective: To ensure that all adequate test cases addressing all aspects discussed in the requirement specification and ensuring the inculcation 


of quality attributes 
i) Security Testing 
ii) Document Test Result 


v) 


Track Testing Programs 


Reliability Growth Testing 


Integration Test 


Shall build a Control and adapt procedure for security testing and shall address the 
security requirements 


Shall establish procedure documenting the test results and shall derive metric to 
evaluate the test results 


Shall establish procedure and implement control in place to track the testing 
configuration items 


Shall establish method and procedure reliability growth testing and shall derive metric 
to evaluate the test results 


Shall establish method and procedure for integration testing and shall derive metric to 
evaluate the test results 


11 


IS 17041 : 2018 


vi) 


vii) 


viii) 


ix) 


x) 


xi) 


xii) 


Partial Failure Test 


Scenario Based Test 


Pilot Testing 


Memory Allocation Testing 


Generation of Audit checklist 


Document Performance Test result 


Document Usability Test result 


2) Final review and evaluation 


Table 2 ( Continued ) 


Shall establish method and procedure partial failure test and shall derive metric to 
evaluate the test results 


Shall establish method and procedure for scenario based testing and shall derive 
metric to evaluate the test results 


Shall establish method and procedure for pilot testing and shall derive metric to 
evaluate the test results 


Shall establish method and procedure for memory allocation testing and shall derive 
metric to evaluate the test results 


Shall develop minimum set of audit checklist for the application based on scope of 
software under development. 


Shall establish procedure for document the performance test results and shall derive 
metric to evaluate the test results 


Shall establish procedure for document the usability test results and shall derive metric 
to evaluate the test results 


Objective: To ensure all functions defined in the requirement specifications pertaining to quality needs are addressed and evaluated 


i) 


v) 


vi) 


vii) 


Final Security Review 


Final Exception Evaluation 


Performance Requirement Evaluation 


Usability Requirement Evaluation 


Reliability Evaluation 


Intellectual property rights 


Protection of Privacy of Information 


e) Software Maintenance 


1) Installation and configuration 


Shall establish a formal method and guideline for review on developed product to 
ensure software security 


Shall establish a formal method and guideline for review on developed product to 
ensure sound exception mechanism 


Shall establish a formal method and guideline for review on performance requirement 
to improve the software performance 


Shall establish a formal method and guideline for review of usability requirement to 
ensure software usability 


Shall establish a formal method and guideline for review of end product to ensure 
software reliability 


Shall establish procedures to ensure compliance with legislative, regulatory and 
contractual requirements related to intellectual property rights and use of proprietary 
software products for development. 


Shall ensure privacy and protection of privacy information within the application 
under development as required in relevant legislation and regulation 


Objective: To prevent unauthorized logical or physical deviation on quality requirement during the installation and configuration 


i) 


ii) 


Set Default Configurations 

Document Security Guidelines 
Document Reliability Requirement in 
user manual 


Fault Logging 
Log Optimization Analysis 


Document Initial Configuration 


Verify and Validate User Manual 


Impact Analysis on Failure 


Outsourced application development 


Shall establish a documented procedure to derive the essential default configurations 
for the desired quality attribute and shall ensure its protection and integrity 


Shall establish a procedure to document the security guidelines and shall address its 
integrity 

Shall list the reliability requirements in the user manual and shall ensure it only 
upgraded version of the requirements are in place of use 


Faults shall be logged, analyzed, and appropriate action taken. 


Shall define procedure for log optimization and ensure its effectives by analyzing and 
appropriate corrective actions in time 


Shall establish a procedure to document the appropriate initial configuration and 
ensure its integrity 


Shall have a formal procedure to verify and validate the user manual and ensure its 
integrity due changes in the application 


Shall establish a method and procedure to study on the impact of failure in the 
application 


Shall establish appropriate control to supervise and monitor the activities of 
development and necessary escrow arrangements. 
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Table 2 ( Concluded ) 


2) Centered maintenance 
Objective: To prevent effectiveness of quality requirement due to localized maintenance of the software application. 


i) Periodic Review Shall define procedure to review the quality review periodically and shall ensure the 
review is adequate 


ii) Generate User Manual Shall establish a controlled process to generate the user manual of the application upon 
the changes in the application 


iii) Maintenance Review Shall define procedure for maintenance review of the quality attributes periodically 
and shall ensure the review is adequate 


iv) Log User Action Audit logs recording user activities, exceptions, and information security events shall 
be produced and kept for an agreed period to assist in future investigations and access 
control monitoring 


v) Archival of records Shall establish process to protect all associated records (logs. specifications, 
configurations etc.,) from loss, destruction, falsification, unauthorized access and 
unauthorized release, in accordance with legislatory, regulatory, contractual and 
business requirements. 


vi) Monitoring and review of stakeholder Shall establish a procedure and principles to regularly monitor, review and audit all 
development processes and activities of associated stakeholders 


f) Information Software Development Incident Management 
1) Reporting information security events and weaknesses 


Objective: To ensure software development process events and weaknesses associated with application are communicated in a manner 
allowing timely corrective action to be taken. 


i) Reporting software development Control 


process events Information security events shall be reported through appropriate management 


channels as quickly as possible. 
ii) Reporting development weaknesses Control 


All employees, contractors and third party users of information systems and services 
shall be required to note and report any observed or suspected development weaknesses 
in systems or services. 


2) Management of information security incidents and improvements 
Objective: To ensure a consistent and effective approach is applied to the management of software development incidents. 


i) Responsibilities and procedures Control 


Management responsibilities and procedures shall be established to ensure a quick, 
effective, and orderly response to software development process related incidents. 


ii) Learning from information security Control 


incidents There shall be mechanism of SDMS in place to enable the types, volumes, and costs 


of information security incidents to be quantified and monitored. 


iii) Collection of evidence Control 


Where a follow-up action against a person or organization after an information 
security incident involves legal action (either civil or criminal), evidence shall be 
collected, retained, and presented to conform to the rules for evidence laid down in the 
relevant jurisdiction(s). 
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